Binary-to-text coding or transfer coding comes from a need to communicate arbitrary binary data over pre-existing communication protocols that were designed to carry only human-readable text. For example, some pre-existing communication protocols may support only American Standard Code for Information Interchange (ASCII), and within that, reserve certain of the ASCII control codes (0-31 and 127) for their own use. Thus, only 94 printable characters may be “safe” to use to convey or transport data. Some currently available techniques for binary-to-text encoding for safe transport of data via email or similar text-based transport include base-64 and base-85 encoding.
Base-64 encoding is typically used for sending binary data via the Multipurpose Internet Mail Extensions (MIME) specification. Implementations of base-64 encoding use 64 of the 94 printable characters for the representation, including the capital letters A-Z, the lowercase letters a-z, the decimal numbers 0-9, two additional value characters (e.g., “/” and “+”; or “.” and “+”; or “−” and “_”), and an additional filler character (e.g., “=”). Base-64 encoding operates by taking 3 bytes (24 bits) at a time of the input to be encoded, joining these 3 bytes into a 24-bit buffer, converting packs of 6 bits of the 24-bit group into 4 index number representations of the 6-bit packs (as 6 bits has a maximum of 64 different binary values), and then converting these index numbers into their corresponding values in the base-64 alphabet table. In summary, base-64 encoding converts 3 uncoded bytes into 4 encoded printable characters.
Base-85 encoding is typically used to encode. IPv6 addresses. Implementations of base-85 encoding use 85 of the 94 printable characters for the representation. For example, most implementations of base-85, encoding use ASCII printable characters from code 33 (“!”) to code 117 (“u”) in their representation. The basis behind base-85 is that 4 bytes (32 bits) can represent 232=4,294,967,296 possible values, while 5 base-85 digits provide 855=4,437,053,125 possible values; enough to provide for a unique representation for each possible 32-bit value. In addition, 32 bits is a popular computer word size. Base-85 encoding operates by taking 4 bytes of input data as a 32-bit binary number (most significant byte first), converting by repeatedly dividing by 85 and taking the remainder into 5 base-85 digits (index numbers), and then encoding the 5 index numbers (most significant first) as printable characters by adding 33 to them to give the corresponding ASCII character (from codes 33 to 117). In summary, base-85 encoding converts 4 uncoded bytes into 5 encoded printable characters.
However, these prior art binary-to-text encoding techniques are only useful for the actual transport of data. The values produced by these encodings cannot be operated on in most cases without decoding. For example, if a document is to be encrypted and transported via email using base-64 encoding, then multiple steps would have to take place. First, the encryption algorithm would run over the document and produce an encrypted result. Then, the base-64 encoder would then run over the encrypted result to create a base-64 equivalent output for safe transport via email. Once the recipient receives the email, they would have to decode using the base-64 coding and run that result through the decryption algorithm.
As the above example makes clear, utilizing cryptographic applications in tandem with a transport-safe encoding mechanism is difficult, if not impossible, to accomplish in some scenarios. Many classes of cryptographic algorithms cannot run without first transcoding the binary-to-text encodings to another representation. Therefore, a solution that allows for transport-safe coding of binary-to-text data in tandem with a cryptographic algorithm application, without having to transcode the binary-to-text encoded data to another representation would be beneficial.